今天參加完 2026 國泰金控技術年會後，我決定先分享。

非常感謝國泰金控，舉辦這麼棒的年會，也很幸運有機會可以參加。

因為前一天還在討論：

一個 Agent 到底該怎麼被評估？

今天在現場看到的，卻是另一個更實際的問題：

當 Agent 真的被放進企業工作裡，接下來會發生什麼？

而且有趣的是，上午談「數位同事」，下午談「AI in IT」與 BMAD，看起來是三個題目，實際上卻可以拼成同一條路：

先找到一條真實 Workflow
        ↓
做出第一版 Agent
        ↓
讓它真的讀文件、Call Tool、碰真實 Case
        ↓
發現 Knowledge / SOP / Tool / 權限的問題
        ↓
開始建立 Memory、Skill、Gate、Evaluation
        ↓
逐步給它更長期的任務與權限
        ↓
Agent
        ↓
Digital Colleague

這跟我原本想像企業導入 Agent 的順序，有一個很大的差異。

不是「資料都準備好了，我們再開始做 Agent」

做企業 AI 很容易出現一種思考方式：

先整理資料
→ 先整理 SOP
→ 先整理 Knowledge
→ 先把 API 準備好
→ 先把權限治理好
→ 先做完整平台
→ 最後開始做 Agent

乍看之下很合理。

但問題是：

你還沒有真的做，怎麼知道自己缺什麼？

一份 SOP 人看得懂，不代表 Agent 能執行。

一份 Word 文件存在，不代表 Agent 能正確讀取裡面的表格、版次與附件。

一個 API 可以被工程師呼叫，也不代表 Agent 知道什麼時候應該 Call、Call 失敗怎麼處理，以及什麼情況根本不應該 Call。

所以這次分享裡，我很喜歡的一個概念是：

先做 Agent。

不是說資料、SOP、Infra 不重要。

而是：

讓第一版 Agent 變成探測器。

拿一條真的 Workflow 給它跑。

真實 Workflow
        ↓
第一版 Agent
        ↓
真文件 / 真 Tool / 真 Case
        ↓
Agent 卡住
        ↓
為什麼卡住？

然後才會真正知道：

是 Knowledge 不夠？

還是 SOP 根本寫不清楚？

還是 Tool 不夠？

還是權限有問題？

還是有很多資深同仁腦中的例外根本沒有被記錄？

還是這件事本來就不應該交給 Agent？

我覺得這跟 FDE 很像。

不是坐在會議室裡把所有需求盤點完成，再花半年打造一個「完整 Agent Platform」。

而是先進工作現場。

從 Agent 到「數位同事」，差別不只是 Memory

上午最有意思的題目，是國泰展示的 Digital Colleague。

一開始我以為「數位同事」大概就是：

Agent
+ Memory
+ Schedule

但實際聽完後，我覺得真正的差異反而是：

企業開始用「管理一個工作角色」的方式管理 Agent。

一般 Agent 可能是：

User
 ↓
Prompt
 ↓
Agent
 ↓
Task Done

數位同事則比較接近：

            Manager / Mentor
                    ↓
Identity → Digital Colleague → Responsibility
                    ↓
          Tools / Permission
                    ↓
        Memory / Skill / Learning
                    ↓
         Schedule / Heartbeat
                    ↓
              Work Log

它開始具有幾個很像「員工」的東西。

1. 它有自己的身分

不是借我的帳號。

不是把自己的 Token 丟給 Agent。

而是它自己有：

• Identity
• Email
• Account
• Permission
• Workspace

這件事看似不起眼，實際上非常重要。

因為只有當 Agent 有獨立身分，我們才有辦法回答：

誰做了這個動作？

它當時有什麼權限？

讀了哪些資料？

修改了什麼？

誰批准它做？

出錯後要撤銷哪個 Account？

所以「數位同事」第一個問題根本不是模型。

而是 IAM。

2. 它有主管，也有 Mentor

這又是我覺得非常有趣的一點。

Agent 不只是：

這是你的 System Prompt，開始工作吧。

而是要知道：

我是誰？
我負責什麼？
誰是我的主管？
誰負責教我？
哪些事情我要自己做？
哪些事情我要回來問？

換成 Agent 架構語言，其實就是：

Persona
+
Responsibility
+
Escalation Rule
+
Human Gate

只是國泰把它翻成一個企業更容易理解的概念：

像帶新人。

這個比喻我覺得比「Autonomous Agent」精準很多。

因為新人也不會第一天進公司，就直接拿 Production Admin 權限。

3. Memory 不能變成「什麼都記」

數位同事另一個核心當然是 Memory。

但現場特別談到一件我最近也一直在研究的問題：

Memory Pollution。

例如某一次 Mentor 跟 Agent 說：

「這個案子重新送審時，要附上前一次的審查結果。」

Agent 能不能學？

可以。

但這句話到底是：

這一次 Case 的補充？

還是：

以後全部案件都適用的新規則？

差很多。

如果每一次聊天都直接變成 Long-term Memory，很快就會變成：

Conversation
Conversation
Conversation
Conversation
        ↓
   全部存進 Memory
        ↓
Agent：我現在到底該相信哪一條？

所以比較合理的 Learning Loop 是：

Mentor Feedback
      ↓
判斷是否值得保存
      ↓
分類
├─ Case Context
├─ Project Memory
├─ Personal Preference
└─ Domain Rule
      ↓
必要時 Human Review
      ↓
正式進入 Skill / Memory

Vanessa：我第一次覺得「數位同事」這個名字是合理的

現場其中一個 Demo 是專案管理數位同事 Vanessa。

它做的事情大概是：

每天檢查 Project Board
        ↓
發現兩個 Task 已經 overdue
而且沒有 Owner
        ↓
分析 Task 需要的 Skill
        ↓
比對 Team Member 的能力與工作量
        ↓
提出適合的人選
        ↓
Human Confirm
        ↓
讀 OneDrive 的 API 文件
        ↓
查 Outlook Calendar
        ↓
建立 Teams Meeting
        ↓
保存整個工作軌跡

如果拆開來看，每一件事情其實都沒有很「AI」。

找 overdue task。

讀文件。

查 Calendar。

排 Meeting。

今天很多 Agent 都做得到。

真正不一樣的是：

它不是等人來問。

它知道：

這個 Project 還在進行
這件事情 overdue
這件事情還沒有 Owner
今天應該要處理

所以數位同事真正新增的不是一個更強的 Reasoning Model。

而是：

Long-running State
+
Memory
+
Schedule / Heartbeat
+
Organization Context
+
Permission

這也是為什麼「一個 Chatbot」跟「一個 Digital Colleague」其實差非常遠。

下午場反而回答了：那這些 Agent 是怎麼長出來的？

下午的 AI in IT 與 BMAD 分享，我覺得剛好補上上午缺的另一半。

上午談的是：

Agent 成熟後，可以變成什麼？

下午談的則比較像：

那企業一開始到底怎麼走到這裡？

答案並不是：

先建一個巨大 Agent Platform

反而比較接近：

很多人開始試 AI
        ↓
內部分享 / Hackathon
        ↓
找出真的有用的 Case
        ↓
做 Agent
        ↓
失敗
        ↓
修改 Persona / Workflow / SOP
        ↓
補 Knowledge / Tool
        ↓
再測
        ↓
有效後才開始 Scale

現場甚至直接提出：

AI PILOT  → 100 天
AI SCALE  → 6 個月
AI FIRST  → 12 個月

這三個數字我不會把它解讀成：

十二個月後，公司所有 IT 都會被 AI 改造完成。

我反而覺得真正重要的是：

探索是有 Deadline 的。

不能一直：

我們還在研究 Agent。
我們還在比較 Framework。
我們還在整理資料。
我們還在做 POC。

100 天後，要有東西可以判斷：

值不值得繼續？

Agent開發工具-BMAD

下午其中一場直接展示了 BMAD。

BMAD 在這裡比較重要的價值，是：

讓 Agent 的工作方法容易被修改。

例如把一個 Agent 拆成：

Persona
Workflow
SOP
Knowledge
Memory
Commands

Domain Expert 跟工程師可以一起調整。

而不是每次流程改變，都重新寫一套 Agent。

所以這裡真正該學的不是：

BMAD > LangGraph

而是：

Agent 的行為
應該可以被持續修改

今天可以用 BMAD。

明天也可以用 Codex、Claude Code、LangGraph，甚至公司自己的 Harness。

真正不能跟著 Framework 一起丟掉的是：

Workflow
SOP
Knowledge
Evaluation
Permission Boundary
Failure Cases

這些才是企業真正累積下來的東西。

當 Agent 碰觸真實世界，才知道哪裡不足

其中一個規格 Review Demo，我覺得非常值得記下來。

概念大概是：

/review spec.docx
        ↓
Agent
        ↓
MCP
        ↓
word-document-server
        ↓
get_document_info
get_document_text
        ↓
Review
        ↓
Report

乍看之下：

不就是叫 LLM Review Word？

但真正重要的是它開始碰「真實世界」。

只要真的開始跑，很快就會發現：

表格怎麼辦？
附件怎麼辦？
版本怎麼辦？
權限怎麼辦？
超大文件怎麼辦？
跨文件 Reference 怎麼辦？

也就是說：

Agent 開始執行工作後，才會反過來告訴你 Infrastructure 哪裡不夠。

所以「先做 Agent」跟「資料下水道很重要」其實沒有矛盾

這也是今天上午、下午兩場放在一起後，我覺得最有意思的地方。

上午另一段分享談到一個詞：

資料下水道。

意思不是一個叫做「資料下水道」的產品。

而是在說那些使用者看不到、很難 Demo、短時間也未必有 ROI 的底層工程。

例如：

Database
Data Definition
Knowledge
Permission
Evaluation
Observability
System Integration

這些東西很無聊。

但沒有它們，上面的產品就很難做。

所以今天的訊息並不是：

不要做 Infra，先做 Agent。

也不是：

先花三年整理 Infra，再開始做 Agent。

而是：

先做一條真 Workflow
        ↓
讓問題浮現
        ↓
知道哪一段 Infra 真的需要補
        ↓
補真正阻礙 Scale 的地基

這個順序我非常認同。

因為這讓 Infra 投資開始有 Evidence。

Day 2 的結論

今天這篇雖然是插曲，但我覺得它反而補了一個很重要的現實世界案例。

我原本研究 Agent Framework，很容易一直問：

LangGraph 怎麼做？

Codex Harness 怎麼做？

BMAD 怎麼做？

Memory 怎麼存？

Evaluation 用哪一套？

但企業真正落地時，問題的順序可能完全相反：

我們到底想改善哪一件工作？
        ↓
先讓 Agent 做一次
        ↓
它失敗在哪？
        ↓
缺的是什麼？
        ↓
再決定要補哪一層

最後才會慢慢長成：

Workflow
+
Knowledge
+
Tool
+
Identity
+
Permission
+
Memory
+
Skill
+
Human Gate
+
Evaluation
+
Observability

做到這裡，它才真的開始像一個「數位同事」。

不要等所有材料都準備好才開始做 Agent。先把 Agent 放進一條真實 Workflow，讓失敗告訴你接下來該準備什麼；但每增加一點自主權，都要用 Evaluation 來證明它值得。

Reference

2026 Cathay Technology Conference

2026 國泰金控技術年會
https://www.cathaytechcon.com.tw/2026CTC/

國泰金控：數位同事創新試驗

國泰金控技術年會 9/15 登場，首度公開 AI「數位同事」創新試驗成果
https://www.cathayholdings.com/holdings/lastest_news/news_archive/newsarticle?newsID=uYwevRwHrUevaoq4sc48iQ

Cathay GAIA

國泰金控 FinTech / GAIA
https://www.cathayholdings.com/holdings/brand/fintech

BMAD

BMAD-METHOD
https://github.com/bmad-code-org/BMAD-METHOD